Programming tools are important for analyzing the performance of computer programs. A variety of program analysis tools are known. Examples include call graph based profiling tools, instruction profiling tools, system call summary tools, dynamic instruction counters, cache memory modeling, input/output summary tools, load and store counters, etc. These tools help computer architects, for example, evaluate how well programs perform on new hardware platforms. Software authors use such tools to analyze their programs and identify critical pieces of code. Compiler writers often use such tools to find out how well their instruction scheduling or branch prediction algorithms perform.
Designing and building such tools or "instruments" can be challenging. In prior art, the instrumentation code itself necessarily affects operation of the computer and therefore sometimes provides inaccurate results. For example, one system known in the prior art for building customized program analysis tools is described in U.S. Pat. No. 5,539,907 to Srivastava. That system provides a single framework for building a wide range of customized program analysis tools. It provides a common infrastructure present in all code-instrument tools, and thus allows the tool designer to operate at a higher level. Essentially, that system allows a procedure call to be inserted before or after any program, procedure, basic block, or instruction. It separates the tool-specific part from the common infrastructure needed in all tools. It provides the infrastructure for object-code manipulation and a high-level view of the program in object-module form. The user defines the tool-specific part in "instrumentation routines" and specifies the points in the application program to be instrumented, the procedure calls to be made, and the arguments to be passed.
The Srivastava system creates a single, modified executable file such that the application program and the user's analysis routines run together in the same address space. See FIG. 1. Information is directly passed from the application program to the analysis routines, through simple procedure calls instead of inter-process communication. The system takes care that analysis routines do not interfere with the program's execution, but because it operates on the same CPU in the same address space, it necessarily affects the system performance. Moreover, that type of system will pollute the machine's resources, such as the instruction cache. Consequently, any behavior of the instruction cache will not be analyzable precisely. Additionally, since the instrumentation segments must be executed along with the application, it bloats the execution time of the application tremendously. Cases of 10 to 20-fold degradation in performance are not uncommon. Finally, the application must be protected from the instrumentation probes, since the probes will certainly change the register state of the machine. Hence, each probe must be encapsulated into a protective shield code. This shield code is quite "expensive."
In view of the foregoing background, a principal object of the present invention is to provide a non-intrusive means for instrumenting an application program. A goal of the present invention is to allow for studying program behavior without affecting the program behavior. That is, an object of the present invention is to allow instrumenting an application program without making any modification to the application program code, or modifying the code in a way that is transparent during execution.
Another object of the present invention is to provide for flexibility and customizing program instruments, by allowing a user to write custom "probes" as needed. A further object of the present invention is to provide for instrumenting the execution of an application program without affecting the machine's resources so that the program analysis is completely accurate.
A final object of the invention is to speed up execution of the analysis itself.